The testing and debugging environment for any software driven processor system requires the ability to stop execution of the system at various points in order to determine the state of the system and then to efficiently restore the system state and to restart execution. This ability to stop or pause execution, to determine the state of the system, and then to restart or resume execution of the system is normally provided by a test utility system for the processor. A test utility system is typically a separate computer system used for testing the processor. This test utility system would normally provide a breakpoint feature and the ability to read/write/modify the memory and registers of the processor system under test.
In a single processor system, testing and debugging in this type of environment usually causes no problems. However, in a multiprocessor system, where the processors are essentially executing asynchronously and the test utilities for the subsystems are independent of each other, this type of testing environment can create problems.
One such problem is that an interruption of program execution by one of the processors oftentimes results in other of the processors interpreting the stoppage as a fault condition because of their inability to communicate with the stopped processor. As a consequence, those other processors erroneously interrupt their own processing, identify that "fault" and attempt inappropriate fault recovery or analysis operations. The interruptions effectively are cascaded among all of the processors to the extent that the entire multiprocessor system operation may be put into a fault analysis and recovery mode when it is not necessary. Obviously, such actions interfere with communication and data processing operations, and are inefficient for fault recovery. Moreover, the stopping of a single processor interferes with the testing program and requires a complex recovery scheme to return all of the processors to normal operating tasks.
Another problem is that the halting of one processor may have been caused by an event in the other processor. To determine possible cause/effect relationships between processors, it is useful to be able to halt and examine the state of each to determine the relationship when any one stops.